home *** CD-ROM | disk | FTP | other *** search
- Path: chronicle.mti.sgi.com!austern
- From: jamshid@io.com (Jamshid Afshar)
- Newsgroups: comp.std.c++
- Subject: Re: Destruction of singletons
- Date: 26 Feb 1996 18:08:20 PST
- Organization: Illuminati Online, Austin, Texas, USA
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <4gtmg0$t59@pentagon.io.com>
- References: <4fvng1$jit@netlab.cs.rpi.edu> <4go9au$l8f@engnews1.Eng.Sun.COM> <9602261828.AA28873@lts.sel.alcatel.de>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: 26 Feb 1996 19:24:16 -0600
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMTJnn0y4NqrwXLNJAQHYGAH+Jnn023ajGxidobGrMaPHlfu8vrlPm+Ox
- z2gn4NEHpHtOOmrK2i7oP9EPs6DGsJEAptPMpCKcXA7cZ1klGdc2LQ==
- =6qph
- Originator: austern@isolde.mti.sgi.com
-
- In article <9602261828.AA28873@lts.sel.alcatel.de>,
- James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
- >In article <4go9au$l8f@engnews1.Eng.Sun.COM> Jamshid Afshar
- ><jamshid@IO.COM> writes:
- >
- >1. As long as there is an active pointer to the memory (a static
- >pointer), Purify will not classify it as a leak.
-
- You're right. I thought there was some kind of report of all unfreed
- memory at program exit.
-
- >In general, I would stress that the prefered solution is to not use
- >the singleton object in any destructors, and use a local static to
- >initialize the pointer. If you do have to use the object in
- >destructors, however, I would still prefer not destructing it to
- >trying to manage the `order of destruction' problem (given that most
- >compiler implementors still consider the order of destruction of
- >static locals undefined).
-
- I agree I would rather have the compiler manage the destruction,
- especially since it's so easy for them to do it (just generate a
- "destroy" function and register it with atexit() when the constructor
- returns).
-
- >|> Actually, the construction and destruction of "local objects of static
- >|> storage duration" is not the same as objects outside of functions. In
- >|> fact, it seems local statics are more poorly specified. According to
- >|> the April '95 Draft, while they are guaranteed to not be constructed
- >|> until (and if) the function is called, exactly when the destructor is
- >|> called is unspecified.
- >
- >I actually believe that it is, and in fact, has been well defined from
- >the ARM.
-
- Okay, I see now that I was misreading section 6.7 Declaration
- Statement in the ARM and April 95 Draft. I took the sentence "Exactly
- when is unspecified" to mean the destructor order is *completely*
- unspecified. I guess the sentence is only referring to the previous
- sentence (ie, "Whether the destructor is called before or as part of
- the atexit() functions is unspecified.").
-
- 5 The destructor for a local object with static storage duration will be
- executed if and only if the variable was constructed. The destructor
- is called either immediately before or as part of the calls of the
- atexit() functions (_lib.support.start.term_). Exactly when is
- unspecified.
-
- >In any case, the Jan. 96 draft makes the question moot, since it
- >explicitly adds the words in the destructor section clarifying that
- >static means both local and non-local.
-
- I assume you're referring to 3.6.3 Termination (analogous to ARM 3.4
- Start and Termination). Btw, has the wording in 6.7 been changed or
- improved? There seems to be some conflict with it and 3.6.3 wrt the
- order of static destructors and atexit() calls.
-
- >|> [...] What should
- >|> have been required IMO is that local statics be destroyed in the
- >|> reverse order they were (fully) constructed.
- >
- >I agree. The remaining weak point in the standard is that it doesn't
- >really specify what is meant by the ordering, entering the
- >constructor, or leaving it.
-
- If the Standard does not require local statics to be destroyed in the
- reverse order they were *fully* constructed, local statics are useless
- to the many programmers who have singletons that use another singleton
- during its construction and destruction (eg, all singletons may report
- their construction and destruction to a "logfile" singleton).
- Programmers will instead have to dynamically create the singletons and
- either never delete them or use the "atexit(&destroy)" technique I
- mentioned. The "atexit(&destroy)" technique isn't difficult (you can
- even wrap it up in a template), but it seems silly for this to be 1)
- unspecified and 2) specified in a manner that makes local statics so
- much less useful.
-
- Jamshid Afshar
- jamshid@io.com
- ---
- [ comp.std.c++ is moderated. To submit articles: Try just posting with your
- newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
- comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
- Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-